Probably not a good idea to drive the motors at 1.77A (or 2.5A peak) when the maximum is 1.2A, or 2.0A for 100ms short period.

i can put my vote for this one as i will in the end change to those

👍 Nice. I will also change to those someday. I've changed to TMC2100 lately and they are just great. Maybe bed leveling will be an option using the stallguard feature fingerscrossed

Probably not a good idea to drive the motors at 1.77A (or 2.5A peak) when the maximum is 1.2A, or 2.0A for 100ms short period.

@teemuatlut I haven't studied the code too closely, just adapted it. What change in code would you recommend to address that?

If you don't mind switching the library being used, I have a working Marlin fork of my own that implements this. You can view the changes here.
I'm also planning on getting the endstopless homing working and finding the right settings for SpreadCycle&StealthChop hybrid mode.

Maybe bed leveling will be an option using the stallguard feature

You know, that hadn't actually occurred to me, but perhaps. The problem is, many beds are on springs, or just have "springiness" in them, and steppers are typically pretty strong. In many cases they might actually harm the machine before they ever stall.

switching the library being used

@teemuatlut Is that a fork of an existing library — and one that works? Or did you implement it yourself? Does it have all the same method signatures as the code represented in this PR, for advanced settings, etc.? I was under the impression the library I linked to here was some official TMC2130 library. Is there no such thing?

You can view the changes here.

There are a lot more changes made in this PR, such as advanced settings, for example. I think it's probably good to preserve those. Is there some way that your branch and this branch can be combined to get the complete suite of options?

Is that a fork of an existing library — and one that works? Or did you implement it yourself?

It's my own library for running TMC2130 steppers. It does work but since I'm the only one ever to use it, there hasn't been much testing yet. I wrote it in the same style as the 26X library and used some code from the SilentStepStick repo. As far as I'm aware of there is no official library, neither from Trinamic nor from Watterot, nor does makertum make any claims to be part of either of them.

There are a lot more changes made in this PR, such as advanced settings, for example. I think it's probably good to preserve those. Is there some way that your branch and this branch can be combined to get the complete suite of options?

Well, this is only my opinion on how to approach this and I surely can provide all those options to Marlin configuration since they are already implemented in the library, but I don't think an end user needs easy access to all the settings when many of them have no application in running a 3DPrinter. If there were an outlier user who needs to alter the driver side stepping wave timings, he could edit the stepper_indirection.cpp file. I'd rather keep the Marlin settings more easily understandable for the average user and provide them with solid default settings.

@thinkyhead regarding bed leveling.: It is possible to reduce the energy the stepper get. The Steppers then get switched on for shorter periods of time. The Idea is energy saving. But this could be used to get a low torque motor. This way the bed or nozzle would not be damaged. The "springiness" could just be an offset if it is equal all over the bed.

But this is just theoretical comment. Haven't tried it.

For reference.

Z axis would be tricky when we're using leadscrews that greatly amplify the torque from the motors and Z also needs to be much more precise compared to X and Y.

I will hopefully have a chance to try this pretty soon. Hoping to integrate 2130's into the MakerArm.

@thinkyhead I've added a macro for users to define their own advanced stepper settings. Maybe this could be something we can use?

Well, you can see I've striven to make it possible to configure settings without diving into files other than the Marlin configuration files. I'd like to preserve that.

I wrote to @makertum concerning the "invalid library" issue, but apparently didn't make myself clear enough. I will continue to inquire.

Thanks for the feedback @makertum — extremely helpful.

I'm excited to see the PR from @teemuatlut. I haven't got too much time to study these units, but I have a project coming up in which I need to use them, and I'm sure bringing it all together will be a master course. In the long run I hope we'll have the best of both libraries, and some user-friendly way to configure everything.

the TMC wakes up with the wrong parameters and fries your coils

Any way to ensure, programmatically, that that can't happen?

@makertum

If the physical SPI connection between the MCU and the TMC goes down, the TMC wakes up with the wrong parameters and fries your coils.

Could you go more into depth about that? If the driver gets reset, wouldn't the IHOLD and IRUN registers be set to 0 (1/32) and the TOFF also to 0, where the driver wouldn't even be turned on?

@thinkyhead @teemuatlut

Whoops, sorry for the missing subjunctive, let me try again:

However, the TMC2130 does not provide a default configuration for a reason: If there was a default configuration and if the physical SPI connection between the MCU and the TMC goes would go down, the TMC wakes would wake up with the wrong default parameters and fries would fry your coils.

So, there's no need to prevent this programmatically: the TMC2130 wakes up in a non-harmful (but also non-functional) state. If the SPI line goes down, or if the naive user forgets to configure the motor current, nothing bad happens. When I wrote the lib, I followed the thinking that a low-level library shouldn't alter this behavior.

Sorry to coming back so late.
@thinkyhead to answer your questions: i think i did only try the RCBugFix branch where i found @makertum 's implementation. Its long here. I don't think that a bug or its really broken. Its just the way of implementation. Advanced section directly talks to the TMC lib. and you can make settings which just are ignored because of other settings. Which is absolutely acceptable, because they are clearly documented in the datasheet. I think at this point the marlin part should validate all settings.
Keep in mind that not everyone wants to read a datasheet, and get familiar with the whole stuff.
User mostly want to enable support, choose current, choose mode.
If the mode needs some advanced settings these should be understandable for the user without the datasheet.

@makertum I don't wanted to blame on you or your lib is great and 100% Working. You did in fact a great job and i'm thankful that you support the community. I did read the Datasheet, i had to. and there is clearly documented if you enable $this you can't use $that. But you can define both in marlin without any feedback that you're doing something wrong. There should be such an option for advanced users to have everything self defined, but this should not the default.
As user i want to:

• define cs pins (maybe part of board settings)
• define which motor has tmc2130
• define current (Maybe automatic current control by default)
• optionally define mode (there should be at least 3 modes, stealthchop, spreadcycle, combined), default combined
• optionally use some other features in the future, like filament runout/grind/skip sensor, or X Y Z endstops, or Z probe
• don't want to get more familiar with the driver as this.

Could imagine to have displayed the filament push force on my display in % (over 100 starts to skip or grind) or get rid of my endstops and have accurate Z probe what is working on every surface.

The reason for my Vote to @teemuatlut 's implementation is the marlin part. That's more like going this way what i mentioned above.

I would welcome to work on one support instead to invest time in two. There is a lot of work to do, both are far away from finished.

@f3rr

optionally define mode (there should be at least 3 modes, stealthchop, spreadcycle, combined), default combined

With combined, do you mean the velocity dependant switching? The three basic modes the drivers support are spreadCycle, stealthChop and the classic constant off time.

There is a lot of work to do, both are far away from finished.

There are a couple fixes and some new features that I want to do when I get the chance, but is there something you'd like to see either in the library itself or as a supported feature in Marlin?

@teemuatlut yes i mean the, velocity dependent mode switching. Classic mode would be nice to have, but i think no one would use it.
About the new features, i think all modes would be nice firstly specially the velocity based switching mode, all other extras what i mentioned are in fact extras.

I can look into it. Let me know if there is something more to make the library more complete.

I just git my RE-ARM for my second printer. Can't wait to give it a try. RE-ARM + RAMPS + Marlin + TMC2130 (delta kossel mini)

Thanks everyone for your feedback on this. We'll continue to get more feedback from users as they start testing this out, I'm sure, and then we'll learn in better detail what they need. We can start a dedicated TMC2130 topic that that time.

@f3rr I'll start a Re-ARM topic pretty soon so we can share our experiences. I've tried flashing it with the 32-bit Marlin I've been hacking together based on bobc's work, but that one continually watchdog-resets. I haven't tried the previous 32-bit branch or @esenapaj's branch yet, but I will soon.

Is there any way to verify that the drivers are connected correctly and configured?
I connected drivers in spi mode but they do not work, command M906 shows zero current, although the default configuration is 1000ma.

You can try the examples that come with the library. Take the X axis belt off first as the examples will start spinning the motor. Do you have the Waterott drivers?

Drivers FYSETC clone.
What outputs to set in the example to test the driver X and Y in the ramps 1.4?

There have been problems with the clone drivers but they should at least move.
The "Simple.ino" example should be already setup for Arduino Mega with RAMPS1.4 and X axis.
You can take off the Y belt too or keep a finger on the power switch if you fear the wrong axis starts to move.

I tried an example, the same thing, no reaction.
I checked the connection of the wires several times,
can I check the connection with the chip by writing and reading the registers? How to do it?

Try adding
Serial.println(TMC2130.DRV_STATUS(), HEX);
to the setup(), right after line 20 where it sets up stealthChop.

If the result is all F or 0, the communication definitely isn't working.

Result is:
0

There must be something wrong with either your wiring, which you've already checked, or the drivers themselves. I don't have the clone drivers myself so I can't do any testing with them but this is not the first time I've heard people having problems with them.

Unsolder the wires and solder again. even the colors of the wires took the same as in the picture: https://hackadaycom.files.wordpress.com/2016/09/tmc-wiring-01.jpg

still does not work:
0
Dir -> 0
Dir -> 1

Change you CS_PIN to 53.

I sealed in the Chinese board two jumpers CFG4 CFG5 (as in the original) and removed the leg NC
magic, everything worked.

marlin standard configuration does not match with the picture on which I was trying to connect?
then the question is, where to get the correct scheme for connecting drivers to the ramps?

The article and the picture was created by another author and he has a library of his own.
I felt like AUX2 was a better place for the CS pins and thus the defaults are found from there. All the CS pins are defined in your pins_RAMPS.h file. You can use this diagram on RepRap wiki to find where the pins physically are.

@alexborro It's hard to tell without comparing the schematics. Maybe they used different components or left some components out completely.

so what legs do I use to make marlin work?
In the file pins_RAMPS.x there are no defined legs for tmc2130
I need to define some legs to make it work?

They're named X_CS_PIN and Y_CS_PIN etc.
You can for example use 63 for X, 40 for Y, 42 for Z and 65 for E.
Make sure to also connect the wires appropriately.

quote from description:

/**

• Enable this for SilentStepStick Trinamic TMC2130 SPI-configurable stepper drivers.
• You'll also need the TMC2130Stepper Arduino library
• (https://github.com/teemuatlut/TMC2130Stepper).
• To use TMC2130 stepper drivers in SPI mode connect your SPI2130 pins to
• the hardware SPI interface on your board and define the required CS pins
• in your pins_MYBOARD.h file. (e.g., RAMPS 1.4 uses AUX3 pins X_CS_PIN 53, Y_CS_PIN 49, etc.).
  */

I tried to use these pins 53,49

everything, like figured out, now works.
Thank you!

Got a question. Where to look a config which the driver is initialized?
Is the dcStep function used?
this function is kind of like it's turned off by a jumper but it can be enabled by software.

The initialization commands are in stepper_indirection.cpp.
dcStep is not used because as far as I know, it requires the steppers to be in full stepping mode.